我成功上架了 4 個 App，每次都是靠 CC 的保姆級教學手把手帶著走。

一直到寫這篇時，才試圖自己一步步搞懂作業程序，細節太多頭昏腦脹之餘，才知道 Apple 的 App Store Connect（ASC）送審被稱為上架大魔王是有道理的。

謠傳 ASC 現在拒絕 Vibe Coding 的作品，說那些是 AI 垃圾。

事情不是這樣的，我查證後看到真的被拒絕或者封號的，是那些被說是「套殼」App，或是只有空殼卻無法驗證的社群功能。（所謂套殼就是改個Logo換個顏色，就當作新App重送的。被抓到據說會整個開發者帳號封號）

先給個定心丸，真的一步一腳印開發，測試，安全驗證，然後好好的寫 ASC 的上架文件而被拒絕的，我自己沒遇過，在脆上打滾三個月也沒聽說。

頂多就是某些程序沒處理好送審送不出去、送出去了遇到大塞車等很久（這是真的，後面再講），或者是被退件調整一下就好。

有點難，但不算是 Vibe Coding 最困難的那關。

我把程序分成五個關卡：專案、打包、準備素材、填寫表單、送審與後續處理。

1）專案：三個名字、兩種版號，先搞清楚哪個是給誰看的

這一關全部在處理「這個 App 是誰、算第幾版、能裝在誰的機器上」，三件事都是設定好就不太能改的。

1.1 名稱

指的是把 Mac 電腦中的專案與應用商店能找到的名稱連結。

有 3 個名詞：專案名稱、Bundle ID、應用商店名稱。

專案名稱用英文或數字寫，Bundle ID 是唯一值，應用商店名稱則是你跟人家介紹這個 App 的時候用的名稱。簡單說就是用 Bundle ID 把你電腦裡的專案跟應用商店名稱串聯。

上面是 Xcode 這一端，下面是 App Store Connect 那一端。同一個 Bundle ID 把兩邊串起來，而商店上顯示的名字、副標題是另外填的，SKU 則只有自己看得到。

1.2 版號

要區分給人看的（Version），跟給 ASC 看的（Build）。

給人看的版號可以區分大中小改版，例如我看過一種說法是 1.1.1 第一個數字是大改版、第二個是更新、第三個是 bug 修復。也有開發者會把第一個放成週年或者第二個放成節慶等等。

當年我遇過 IT 主管跟公司內部說「人家 Line 一年改 40 到 50 次，我們不要怕改版」，指的就是第二個數字的更迭。

Version 要在兩個地方各打一次，而且順序不能反。 先在 Xcode 的 Target 底下 General 分頁把 Version 欄位改成新版號，這個數字會被打包進去；再到 ASC 左側「iOS App」旁邊的加號按下去，輸入同一個版號，ASC 才會生出那一版的頁面。

反過來做會卡住：只在 ASC 開了 1.2、Xcode 還停在 1.1，那個版本頁的建置版本清單會一直是空的，因為它只列版號相同的 build。你會以為自己上傳失敗。

給 ASC 看的 Build 號，只有 Xcode 有。 ASC 那邊是從已上傳的清單裡挑一個，沒有讓你填的地方。它在 Organizer 上傳時如果勾了「自動管理建置號」會自動加一，沒勾就要自己改。

這裡有一條硬規則：Build 號只增不減，每次上傳都必須比上一次大，就算 Version 沒變也一樣。

網路上有些教材說不用管 Build 版號變動，我覺得多少看一下，確保都有在增加，以防有什麼小細節沒注意到。

1.3 這個 App 在哪裡能用

要注意的是最低可接受的 OS 版本，以及除了 iPhone 外還要給 iPad 或者 Mac 用嗎。

OS 版本部分，我沒有選擇最低版，因為我要用的照片美學評分在 iOS 18 以下不適用，所以我沒有像一般網路建議的直接給他選最低版，以求涵蓋率最大。你就看你的 App 開發有用到什麼新功能而定。

硬體部分，一般建議沒有要開放 iPad 的時候就不用勾 iPad 能用，否則審核員會真的拿 iPad 試試，增加一個被擋下來的風險。

我在送審《這餐》的時候勾了 iPhone 跟 iPad，審核員就真的拿 iPad 測，然後被退件了。

2）打包：按了 Distribute，不等於 ASC 馬上看得到

這一關做的是把電腦裡的東西送上去，然後等它在 ASC 出現。我卡最久的就是「等它出現」。

2.1 分發（Distribute）

我在打包《這場》的時候，開發得很高興，一路往下走，在 Xcode 裡面都按了 Distribute 了，結果去 ASC 打開空空如也，我還問 CC：

建制版本還沒看到
為什麼上次上傳時，testflight 秒成功。這次這麼久？
1.0 出現了

原因是 Apple 收到檔案之後要跑一段處理（processing），時間不固定，通常一次幾十秒，但這一次遇到了三十幾分鐘。上傳成功不等於馬上選得到，畫面上會寫「處理中」。

上面那列寫著「處理中」，下面同一時間的版本頁卻顯示「沒有建置版本」。當時我就是卡在這裡。

同一段時間我還踩了另一個坑：ASC 的套件識別碼那個下拉選單裡，有兩個長得很像的選項，我眼殘選成「XC com yojuhsu SlidePhotoApp」。

而如果你的下拉選單裡根本找不到自己的 App，那是另一件事：Bundle ID 還沒去開發者網站註冊，沒註冊就不會出現在選單裡。我在做《這隻》的時候就遇過，選單裡只有 this talk。

2.2 掛勾版號

Distribute 成功後，在 TestFlight 分頁的「建置版本上傳」區塊，就會看到新的 Build 數字，已經上傳成功。

如果要首次送審，就是選一個最大的 Build 數字掛在 Version 上面，不然送審勾到舊版，就心酸了。

如果是更版送審，記得先在 Xcode 改 Version 版號、在 ASC 開一個同號的新版本，再去找當下最大的 Build 掛上。

3）素材：手機直接截的圖，尺寸不合規

這一關準備的是陌生人會看到的東西，截圖、文案、隱私權網頁。三樣我都踩過雷。

3.1 截圖

iPhone 的話需要 6.5 吋那一組尺寸，但是手機直接截是 1320×2868，ASC 要 1242×2688 或 1284×2778。比例不同，硬裁會失敗，我的解法是換模擬器機型重截。

雖然我都交給 CC，但給它正確的指令，可以降低反覆重來的時間浪費，也避免你一試再試的挫折。

由於我開發時候用的都是自己的照片做測試，截圖時候難免有人臉，或者是做《這場》簡報軟體的時候裁到別人的簡報等。這些我都是請 CC 幫我把圖片做點調整，或者製圖避免隱私權或其他智慧財產權相關問題。

如果有要上架 iPad 自然是再處理 iPad 截圖，以及 Mac 的話就是 Mac 截圖等。

3.2 文案

這裡要準備產品名稱之外、還有描述，以及改版說明等。

這些是很棒的 ASO，App Store Optimization 的基礎，有人查詢相關關鍵字的時候能讓你的產品露出。

我看到網路上很多人寫說這裡讓 AI 根據程式碼寫寫就好，我一開始也是這樣想：有這麼多格子要填，文書工作能不能都交給 AI 啊。

但想想讀者決定要不要下載這個 App 的最後一哩路就是看到這幾句話了，我至少先看一眼 CC 寫什麼再決定要不要送出吧，結果它寫的非常直白，大體就是寫說：

這個 App 不做ＯＯ，不做ＸＸ，只做ＯＯ

講了一堆描述句與否定句，但一點為什麼需要這個，誰需要這個，起心動念以及設計心得等等都沒有放，我還是自己寫了一版，再請它幫我修正。

3.3 隱私權網頁

倒是隱私權網頁，我就是請 CC 寫了。

這裡有個小到好笑的坑：網址貼進 ASC 被擋下來，訊息寫「URL 格式錯誤。格式須為 http://example.com」。我的網址格式從頭到尾都是對的，真正的原因是手殘，貼上去的時候後面多了一個空格。

那個訊息差點把我引到完全錯的方向，我跟 CC 開始懷疑是不是不能用 https、是不是不能有子路徑。

看到格式錯誤，先檢查有沒有多餘空白。

4）表單：格子很多，但第一次可以幾乎都填否

要填的有審核資訊、支援網址、版權、審核聯絡人、出口合規、類別、定價與供應地區。我當初看到這麼多項目都昏了，請 CC 一格格建議該怎麼填，最後再選剛起床大腦比較清醒的時候一格格複製貼上。

主要是兩件事：首先不要被嚇到、其次第一次先盡量簡化。

例如出口合規與否，有沒有要進歐盟，有沒有未成年隱私權等等，只要開發的目的確實沒有涵蓋這些就請先填否。

當然也不是亂填，是跟 AI 好好討論後的誠實填寫。

值得一提的有幾件事：審核資訊、多語系、IAP。

審核資訊

網路上很多人說，如果 App 沒有做登入功能就不用填寫審核資訊。我也都是這樣填，結果在《這餐》踩到地雷被退件。

退件的理由是審核員無法驗證功能，要求提供 demo 帳號。但我根本沒有帳號系統，這條路不存在。

解法寫在 Apple 的退件信裡：內建一個示範模式也是可以接受的。 所以《這餐》後來多了一個「先看看示範資料」的入口，讓審核員打開就有東西可以看。

多語系

我上架《這趟》的時候野心勃勃，問 CC 可不可以乾脆多語系一起上。它力勸我不要，因為每個語系不是 ASC 換字就好，必須從 UI 開始更改，更要有對該語系的了解，以及問題回答。如果連流程都還不熟悉，就開始跑複雜模式，只會給自己找麻煩。

App 內購（IAP）

我大概送審到差不多第 3 個左右，就很想試試把打賞收費做上去。但 CC 提醒我：IAP 的審核特別嚴格，與其一開始就挑戰，不如先送審第一次，頭過身就過，之後才是收費功能的上架。

至於收費功能送審的多個選項迴圈選擇失利，以至於我被退件要求重來，那就是另一回事了。

總之，在表單部分請盡量給自己簡單模式，然後誠實與你的 AI 討論，一一確認後再按送出。

5）送審與後續：不是按下送審就萬事太平，記得看信件

等候時間且不提，這裡我可是累計了 4 次的被駁回紀錄啊，整理後重送就好。

發布模式

可以選手動或自動。我自己是都選手動發佈，主要是我想掌握發布的時機，以及那個可以第一時間昭告親朋好友的成就感。我看有些網友會選自動，那也很好，看你喜歡。

審核信件

我收集到了四封退件信，沒有一次是程式問題，是文案、空狀態與程序的問題。下面每一條前面是踩到的條款代號，後面是說明。

• 5.1.1(iv) 這場：權限前置畫面的按鈕寫「允許讀取相簿」，Apple 要求改成「繼續」或「下一步」
• 2.3 這隻：描述寫了早安圖與地圖，審核員找不到
• 2.1(a) 這餐：審核機 iPad 相簿沒有食物照片，打開一片空白，要求 demo 帳號
• 2.1(b) 這隻 1.1：IAP 沒跟 build 一起送審

第一次被退，我再度慌張地找 CC 確認，但除了《這趟》之外，另外 3 個 App 都被退，回信說明之後也都快速過關。最後我已經很平常心的面對這些小障礙了。

以上是 2026 年 7 月到 8 月，四個 App 實際走過的流程。Apple 的後台介面每年都在改，你看到的畫面不一樣就以畫面為準。

心得

因為上架細節太多，寫作這篇程序回顧文時，我再度請 CC 啟動保姆級格放教學。我把我練習多次後的記憶，按照每個步驟的注意事項，以及我踩過的雷、記錯的事，逐一復盤糾正與整理。

老實說，到現在我還是張冠李戴，並且消耗了很多精力。

不過如果再走一次送審流程，我會一樣謹慎，但已經不覺得是大魔王關卡了。

主要是對於 Xcode、ASC、IAP 等等的角色與作用都比較有熟悉感，熟悉減少慌張。再加上踩的雷多了，也就沒那麼怕痛了。

這個系列同步寫在我的部落格：yojuhsu.com/blog

前一篇：【Day19】AI 叫我去刷卡？所以我找了第三方來檢查
下一篇：【Day21】審核到底是 9 小時，還是 109 小時？